いま、あらためて考えてみるアカウント管理 with IaC / Account management with IaC

Platform Engineering Meetup Online #4
https://platformengineering.connpass.com/event/364213/

Transcript

1. ©MIXI 1 いま、あらためて考えてみる アカウント管理 with IaC 2025/08/20 Platform Engineering Meetup Online #4 @kohbis
2. 2 ©MIXI About Me Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X / @kohbis
3. 3 ©MIXI お話しすること（from PEK2025 proposal） 「いまさらIaCの話？」 とつい思ってしまうほど、もはやInfrastructure as Code（IaC）は私たちの⽇々の開発運⽤にとっ て⽋かせないものになりました。 しかし、クラウドやSaaSにおけるアカウントや権限の管理は、依 然として⼿動や属⼈的な運⽤に頼っているケースが少なくありません。 本セッションでは、「なぜアカウント管理にIaCを適⽤すべきなのか？」という原点に⽴ち返り、属 ⼈化や設定ミスといった運⽤課題にどう⽴ち向かうかを⾒直します。 IaCツールの代表格である Terraformを⽤いた現場の実例とともに、コードによる権限管理の再現性や可視性、GitOpsを活⽤ した変更管理、組織全体でのスケーラブルな運⽤⽅法を紹介します。また、⽣成AIがIaCにもたらす 影響や新たな価値についても考察します。 あえていま、IaCによるアカウント管理を⼀緒に考えてみましょう！
4. 4 ©MIXI 本セッションの⽬的 • IaCを導⼊していない⽅の、検討‧導⼊のモチベーションになること • IaCを検討‧導⼊している⽅の、意思決定の⼀助になること   • IaCを導⼊しているがアカウント管理には活⽤していない⽅の、次のヒントになること • IaCをアカウント管理でも活⽤している⽅の、知⾒を引き出すこと
5. 5 ©MIXI Infrastructure as Code（IaC）のおさらい（1/3） • インフラなどの構成‧設定を、宣⾔的なコードで管理‧プロビジョニングする • 「宣⾔的」？ • 最終状態をコードで定義し、実際の状態との差分をツールが⾃動で調整 する • 基本的に「コードが唯⼀の正」となる • さまざまなツールがある（以下、AWSの場合） • Terraform … HashiCorp製。HCL（HashiCorp Configuration Language） • AWS CloudFormation … AWSマネージドサービス。JSONまたはYAML • Cloud Development Kit（CDK）… TypeScript, Python, Javaなど • Pulumi … Node.js, Python, Goなど
6. 6 ©MIXI Infrastructure as Code（IaC）のおさらい（2/3） • コードで管理するため、GitなどのVCSと組み合わせてCI/CD可能（GitOps） • 再現性 … 同じコードから同じ（または同じ構成で複数の）環境を構築できる • 可視性 … コードの意図や変更差分をGitHub上などで確認できる • 監査性 … 誰が‧いつ‧何を変更したか履歴が残る、承認ステップを組み込め る • 運⽤容易性 … ⾃動化することで⼈⼿を介さずに適⽤できる
7. 7 ©MIXI Infrastructure as Code（IaC）のおさらい（3/3） 『Terraformではじめる実践IaC』1.1より抜粋 作業⼿順書を作成する場合 1. 作業⼿順書を⾃然⾔語で記述 2. ⾃然⾔語を⼈間が解釈して作業実施 3. 作業結果を振り返る IaCでインフラストラクチャを記載する場合 1. 構成をコードで記述 2. コードをIaCツールに読み込ませ、ツールが作業を実⾏ 3. 作業結果の振り返り https://www.oreilly.co.jp/books/9784814400133/
8. 8 ©MIXI Infrastructure as Code（IaC）のおさらい（おまけ） IaCツールの歴史（出典：Wikipedia） 年 ツール 2005 Puppet 2009 Chef 2011 AWS CloudFormation 2012 Ansible 2014 Terraform 2018 AWS CDK 2018 Crossplane 2024 OpenTofu
9. 9 ©MIXI クラウドインフラの管理では当たり前（？）になったIaC • 特にクラウドインフラの運⽤においては、ありとあらゆるリソースのIaC管理が普及 （引⽤可能な数字が⾒つけられず 肌感） • コンピューティング • ネットワーク • ストレージ など • チーム開発におけるGit運⽤、Pull Requests⽂化との相性◎ • ⽇常化したコード修正‧レビュー‧承認ステップをそのまま適⽤できる • CI/CDと組み合わせることで、誰か実⾏しても同じ結果や品質になることを保証できる • 「ひとによってやり⽅が違う」「⼿順書が古い」状態を回避できる • 不正またはポリシーに違反する変更を⾃動的に検知できる サービスを構成する要素は、コードで管理するべきメリットが多々ある
10. 10 ©MIXI 「サービスを構成する要素」？
11. 11 ©MIXI IaCで クラウドのリソース管理してるひと 
12. 12 ©MIXI IaCで クラウドやSaaSの アカウント管理してるひと 
13. 13 ©MIXI たぶんちょっとだけ⼿が下がった（はず）
14. 14 ©MIXI 「アカウント」もサービスを構成する重要な要素のひとつ • クラウドやXaaSのアカウントや権限の設計を誤るとサービス全体の安全性に直結する （例） • AWS, GCP, Azure • Cloudflare • GitHub, GitLab • New Relic, Datadog • Hashicorp Cloud Platform クラウドのアカウントや権限管理はリソース管理の延⻑で実施しやすい ⼀⽅で、サービスを構成するために必要な 「アカウント」や「権限」は⽇々増えていく （そもそも "Infrastructure" as Codeでは？と思っても今⽇は⼤⽬に⾒てください）
15. 15 ©MIXI 「アカウント管理」でよくある課題 • 管理業務の属⼈化、設定ミス（ユーザー誤り、過剰権限） • 「誰が」「何のために」その権限が必要なのか不明、作業の証跡不⾜ • 時間経過に伴って不要になった権限、退職者アカウントの残存、 監査‧規格に則した権限棚卸し（ISMS, J-SOX, PCI DSS, etc.） • ⼩さな変更が多い、即時対応が求められる、責任範囲（管理者）があいまい
16. 16 ©MIXI TSURAI
17. 17 ©MIXI 「アカウント管理」でよくある課題 〜IaCによるアプローチ〜 • 管理業務の属⼈化、設定ミス（ユーザー誤り、過剰権限） 作業者は「コードを修正すること」だけを強制される（再現性） • 「誰が」「何のために」その権限が必要なのか不明 コード、またはPull Requests上に変更の意図や差分が確認できる（可視性） • 時間経過に伴って不要になった権限、退職者アカウントの残存、 監査‧規格に則した権限棚卸し（ISMS, J-SOX, PCI DSS, etc.） コード規約‧ポリシーの強制‧⼀括反映（再現性含む） Git（GitHub）上で変更‧承認の履歴を記録（監査性） • ⼩さな変更が多い、即時対応が求められる、責任範囲（管理者）があいまい 作業者は「コード修正すること」のみを対応、CI/CDによる⾃動化も可能 GitHubの CODEOWNERS などで管理者（レビュアー）の明確化（運⽤容易性）
18. 18 ©MIXI （例）GitHubアカウント 〜⼿動の場合〜 1. 管理者がGitHubにログイン 2. メンバーをOrganizationに招待 3. メンバーごとに Roleを割り当て 4. 必要に応じてTeamを作成し、リポジトリ単位で権限を付与 5. 定期棚卸し • 定期的にOrganization画⾯から全メンバーを確認 • 退職者や不要なアカウントを⼿動で削除 • 権限が過剰でないかを確認 （例）Adminが割り当てられているメンバーの棚卸し • GitHub ActionsやGitHub CLIによって作業の簡略化はある程度可能 • 変更作業‧差分のレビューや作業の証跡は残らない • 正確にはGitHubならAudit Logがある
19. 19 ©MIXI （例）GitHubアカウント 〜IaC（Terraform ※1）の場合〜 1. メンバー‧Team‧Roleをリソース定義 2. Pull Requests作成、コード差分＆ terraform plan のレビュー 3. CI/CDによる terraform apply 4. 定期棚卸し • terraform plan によるドリフト（コードと実態の乖離）を検出 • 過剰な権限や退職者のチェックはコード検索と修正で完結 • 作業の証跡 ≒ Git（GitHub）の履歴 ※1 GitHub Provider https://registry.terraform.io/providers/integrations/github/latest/docs
20. 20 ©MIXI （例）GitHubアカウント 〜⼿動 vs IaC（Terraform）〜 手動の場合 IaC（Terraform）の場合 再現性 人手による操作差異、設定ミス 同じコードから同じ設定 可視性 画面でしか確認できず差分が不明瞭 コード化された差分をレビュー可能 監査性 ログやスクショによる補完 Pull RequestsやGitの履歴が証跡 運用容易性 都度GUI操作が必要 CI/CDで自動的に適用可能
21. 21 ©MIXI アカウント管理へのIaC導⼊は「⼩さく始める」ができる • 全社的な組織構成によらず、局所的に導⼊できるのがIaCの⼤きなメリット （例） • 全社の情シス部⾨にてOktaやGoogle Workspaceのアカウントが発⾏されている • AWSアカウントやGitHub Organizationの管理は事業部に移譲されている • 個別のSaaS契約やその管理は事業部に責任がある • まずは1つの権限や1つのSaaSからコード化してみる • Pull Requestsのテンプレートや最⼩限のモジュール作成など作成してみる • あとからリファクタリングは可能 • ドリフト検出機能やテスト機能の活⽤によって安全に作業可能 • 事業部単位やチーム単位でも独⽴して導⼊できる • 「⼩さな成功」を積み重ねて、徐々に導⼊範囲を広げていくことができる • PoCから始めることで、⼼理的ハードルも下げられる
22. 22 ©MIXI アカウント管理を IaC化（コード化）できたということは？
23. 23 ©MIXI 運⽤担当者だけでなく 開発者も作業の⼀部をできるようになる！
24. 24 ©MIXI アカウント管理を"⺠主化"する 従来 • アカウントや権限変更は依頼に基づき、運⽤担当者が対応 • 開発者 → 運⽤担当者に依頼 → 運⽤担当者が作業（依頼者は作業待ち）→ 作業完了を連絡 コード化後 • 通常の開発同様にPR起票、理由を記載することでレビューを経て安全に適⽤ • 開発者 → PR起票 → 運⽤担当者 or 承認者がレビュー → CI/CDで⾃動適⽤ • 依頼作業待ちの時間を減らし、リードタイムを短縮 • 属⼈化を解消し、CODEOWNERS の設定などで上⻑承認必須化など責任範囲も明確にでき る • 必ずしも運⽤担当チームが中央集権的に管理する必要がなくなる
25. 25 ©MIXI アカウント管理を"⺠主化"するための⼯夫 • コードを書く以上、少なからずIaCツールへの知識が必要になる 可能な限り負担なく作業してもらいたい！ • Terraformの場合 for_each や module などを⽤いて、開発者ができるだけHCLを書く必要を なくしていく（アカウント限らず有効） ▼ 少なからずHCLに関する知識が必要 ▼ HCLに関する知識を必要とせずに「⾏追加」するだけ
26. 26 ©MIXI コードが開発者フレンドリーに なったということは？
27. 27 ©MIXI AIにとってもフレンドリー！
28. 28 ©MIXI IaC x AI（1/2） 開発者とってフレンドリー • 「コード」で表現されているため、⽇々の開発と同様に作業ができる • コードが構造化され、⼈間が読み書きしやすい • 多数のファイルを修正する必要がなく、修正作業が簡潔になる AIにとってもフレンドリー • 「アカウント管理」が「コード」で表現されているメリットが⼤きい • ⼀般的なプログラミング⾔語やHCLなどの⽣成や解析 • コードが構造化され、適切にパターン化‧モジュール化されたIaCは⽣成AIも作業しやすい • 分散した情報を横断的に読み解く必要がなく、AIが⼀貫したコンテキストで処理できる • コーディングエージェントに対応したルール化によってより効率的になる
29. 29 ©MIXI IaC x AI（2/2） ⽣成AIによってコーディング‧レビューなどでメリットが多数 • コーディングの⾃動化 • ⾃然⾔語から差分作成、Pull Requestsを起票 • ⾃動レビューによるレビュアーの負担軽減 • 最⼩権限ポリシーの⾃動提案 • 運⽤‧セキュリティ上、危険なコードの指摘 • 既存のコードや過去のPull Requestsから、リポジトリ内での（フォーマッタで検知できない ような）コーディングの傾向を学習 • InstructionやMCPなどでコンテキストを付与して、ベストプラクティスに従った or ベターな コードへの改善 など 運⽤担当者またはチームに属⼈化していた知識を 組織全体で共有し、誰もが活⽤できる形に変えられる
30. 30 ©MIXI とか⾔いながら
31. 31 ©MIXI IaC⾃体の運⽤負荷も存在する
32. 32 ©MIXI IaC運⽤の負荷 • コードやモジュールの設計‧メンテナンスに⼯数が必要 • Stateファイルの保管‧ロック‧セキュリティを考慮する必要がある • バージョンアップに伴う破壊的変更への追従が発⽣する • Pull Requestベースの変更管理でレビュー⼯数も発⽣する • チームにIaC知識が浸透するまでの教育コストがある • ツールごとの制約やベンダーロックインも考慮する必要がある メリットとデメリット（コスト）を天秤にかけつつ、「⼩さく始める」で最適化
33. 33 ©MIXI まとめ • Infrastructure as Code（IaC）によるメリットはたくさん • アカウント管理にもIaCを導⼊することのメリットがたくさん • 再現性 • 可視性 • ⾃動化 • 監査性 など • 属⼈化を解消し、内部統制と効率化を両⽴できるになる • まずは 1つの権限∕1つのSaaS から⼩さく始めてみるとよい（かも？）
34. 34 ©MIXI さいごに https://team.mitene.us WE ARE HIRING!!!
35. ©MIXI 35 ありがとうございました